Since there's no LiveView test for that, what about adding a JS test? So we can ensure it will filter the apps based on the search criteria

@aleDsz yes, that's what I'm thinking about doing, maybe with https://github.com/ftes/phoenix_test_playwright or https://github.com/elixir-wallaby/wallaby

I don't think it is worth adding the complexity of browser testing for this feature. One option is to use hooks (or another client-side abstraction), and unit test that instead, like we do here: https://github.com/livebook-dev/livebook/tree/main/assets/test/hooks

The hooks directory actually only has unit tests for some specific encapsulated classes that we use from hooks. I don't think there's an easy way to unit test it, because it requires the page structure.

But I don't think adding browser testing for this specifically is worth it either.

I don't think there's an easy way to unit test it, because it requires the page structure.

Exactly.

But I don't think adding browser testing for this specifically is worth it either.

The /apps page is the home page for Livebook apps' users. It can be the first page internal users of Livebook app sees whenever they're using their Livebook-based internal tools.

Given that, I’d say this page is important enough to justify having end-to-end tests for it.

Then move the rendering of the apps to the client, using a simple rendering like lit? Or postpone this pull request. I am strongly against adding end-to-end tests, it will add more complexity to a test suite that is already complex because of how teams are setup, and it will impact all Livebook contributors. If this was on the teams side, I would have fewer complaints.

Then move the rendering of the apps to the client, using a simple rendering like lit?

I think that would add even more unnecessary complexity than having an end-to-end test.

I am strongly against adding end-to-end tests, it will add more complexity to a test suite that is already complex because of how teams are setup

I understand the cost.

One thing we can do is run those tests by default only in the CI, as we already do for other parts of the test suite, so contributors don't have to deal with them.

We should use something like this.js().show(card) and this.js().hide(card) (docs), otherwise LV rerender can override the page with unfiltered state.

Similarly here, we need phx-update="ignore" on this element. And I think we also need ignore on the parent of input/select.

To test you can deploy a new app in another tab and see which state gets incorrectly reverted.

The hooks directory actually only has unit tests for some specific encapsulated classes that we use from hooks. I don't think there's an easy way to unit test it, because it requires the page structure.

But I don't think adding browser testing for this specifically is worth it either.